We call xvfb with the command directly in https://github.com/pandas-dev/pandas/blob/master/ci/run_tests.sh#L33, we shouldn't need that. Is that causing any trouble?

OK, thanks. No idea if it's causing issues. I'll rerun the travis job that has been failing a few times to see if it's present on this branch.

Dunno if this is related, but I do see

QXcbClipboard::setMimeData: Cannot set X11 selection owner

In the output log. I assume that the tests are run under the same user as everything else though, so not sure what that actually means.

Things passed with a93b9d8. Going to restart the problematic job a few times.

1 / 1

I've been going through logs. The "Cannot set X11 selection owner" warning seems relevant. It's been present in all the failed builds, and absent in all the successful ones.

I found this post very useful when dealing with clipboard test errors in the past, and trying to understand how things work: https://www.uninformativ.de/blog/postings/2017-04-02/0/POSTING-en.html

Still very confused, and I don't know how to fix that error yet, but I think the article is worth reading.

I'm wondering if we're copying and pasting too fast, and if a short sleep in between would get rid of the error...

I have one theory to try out before then. I'm worried about the module-level to_clipboard we attempt. That would be executed on import. Putting that behind a fixture.

With some luck #29712 may fix the problem. Some info here: http://elementalselenium.com/tips/38-headless

If that doesn't work, I'll probably focus on moving the db builds to GitHub actions, where I guess the X server is provided, we don't need xvfb-run, and I think the test won't fail.

Thanks. Hopefully #29712 fixes it.